The core network of Universal Mobile Telecommunications System (UMTS) is divided into subsystems of Circuit Switch, Packet Switch (PS) and IP Multimedia System (IMS) since the stage of the 3rd Generation Partnership Project (3GPP) R5.
The IMS architecture defined in 3GPP standards addresses comprehensively crucial operatability issues, such as roam charging, Quality of Service (QoS) and security guarantee, required to be solved for provision of multimedia services over an IP bearer, and its architecture and idea have been accepted commonly in the industry. Both the 3GPP2 and the TISPAN define the respective IP multimedia network architectures and service systems with the 3GPP model as a basis and reference. The 3GPP has been in the research of projects regarding interworking of UMTS via Wireless Local Area Network (WLAN) access such as the Interworking of WLAN (I-WLAN), fixed broadband access to IMS such as the Fixed Broadband access to IMS (FBI), various access technologies oriented all-IP network such as All-IP Network (AIPN), etc. A subscriber may have an access to the IMS via access networks on the basis of different access technologies by means of a single multimode User Equipment (UE) or different types of UEs in accordance with his/her subscription to obtain uniform multimedia services including a Voice over IP (VoIP) service and the like.
A service platform in the IMS architecture can also provide a voice service over IP, i.e. a VoIP service, and an operator can apply different charging rates to a CS domain voice service and an IMS domain voice service respectively. Therefore, for a call or session to be established, the route to the called subscriber in the CS domain or the IMS domain shall be selected in accordance with a routing policy of the operator and a preference setting of the subscriber. Further, because a CS domain voice service or an IMS domain voice service can also be provided by the operator in different regions respectively, continuity of an established call or session shall be ensured when the voice service switching between the CS domain and the IMS domain occurs to the subscriber due to mobility of the subscriber, so as to ensure a smooth transition of the voice service between the two different domains.
Currently, the 3GPP just approved a project for a research on the issue regarding service continuity between a CS call and a VoIP service provided by accessing to IMS via IP-Connectivity Access Network IP (IP-CAN), and the research focuses on routing control and switching for the called party.
The 3GPP currently proposes a call control solution of IMS control static anchoring to address the issue of switching between two domains such as the CS domain and the IMS domain. A core idea of the solution lies in that a call/session initiated from either the CS domain or the IMS domain is triggered to an Application Server (AS) in the IMS domain, and the AS performs anchoring control on the call/session. Thus, the AS controls subsequent switching of the anchored call/session regardless of subsequent occurrence of domain switching from the CS domain to the IMS domain or of domain switching from the IMS domain to the CS domain.
For the session control in the IMS, an anchoring point AS can be inserted conveniently in a call path to control a session, in other words, the session is triggered to the AS by definition of an initial Filter Criteria (iFC). For session control in the CS domain, it is not easy to insert an anchoring point AS in a call path. Therefore, for the purpose of triggering a call initiated from the CS domain to an anchoring point AS, the 3GPP specification has currently specified a plurality of solutions include that: for an initial call initiated with the CS domain being the calling party, in other words, for a call initiated from the calling party Visited Mobile Switching Center (VMSC) upon receipt of a call establishment message from a UE, the call can be routed to the anchoring point AS in two control modes including network side routing control, i.e. a scheme utilizing the Customized Applications for Mobile network Enhanced Logic (CAMEL), and user equipment side routing control, i.e. a scheme utilizing the Unstructured Supplementary Service Data (USSD) and Notify; and for an initial call initiated with the CS domain being the called party, i.e. a call initiated by a Gateway Mobile Switch Center (GMSC) in the home network of the called party in accordance with an analysis of information of the called party upon receipt of a call from the calling party, the call can be routed to the anchoring point AS with use of the CAMEL scheme and a signaling intercept scheme.
Such function of routing an initial call to another domain is referred to as a Domain Selection Function (DSF). In the CS domain, an entity with the DSF function can be a Global System for Mobile communications-Service Control Function (gsmSCF), and in the IMS domain, an entity with the DSF function can be an AS. The routing decision entity gsmSCF in the CS domain can be located in the same physical entity as the routing decision entity AS in the IMS domain.
A primary principle by which the anchoring control function in the AS described above implements domain switching lies in that: in initial establishment of a call, a UE (A), for example, initiates a call to a UE (B), a gsmSCF or an AS with the DSF function inserts an anchoring point AS in a call path of the calling party UE (A), and the anchoring point AS enables a Back to Back User Agent (B2BUA) function to divide the call of the calling party into two segments, an AS terminated segment and an AS initiated segment. The AS terminated segment is a call segment between the UE (A) and the anchoring point AS, and the AS initiated segment is a call segment between the anchoring point AS and the UE (B). Subsequently during the call, when detecting that a domain switching condition is satisfied, a UE (A′) desires to switch the ongoing call from the UE (A) to the UE (A′) for subsequent control on the call, and at this time, the UE (A′) initiates a new call for the AS performing anchoring control on the current call. The AS receives the call and determines that domain switching is required, and connects the call newly initiated by the UE (A′) to the AS initiated segment and then releases the call of the AS terminated segment. Thus, under the control of the anchoring point AS, the call is connected for the UE (A′) and the UE (B), and the previous call segment between the UE (A) and the AS is released, thereby accomplishing switching from the UE (A) to the UE (A′). Such function of performing anchoring control on a call and switching of the call upon occurrence of domain switching is referred to as Domain Transfer Function (DTF), and in the static anchoring point solution, an entity with the DTF function is an AS in the IMS domain. The routing decision point gsmSCF or AS with the DSF function can be located in the same physical entity as the AS with the DTF function.
Here, the UE (A) can be a CS domain User Equipment, the UE (A′) can be an IMS domain User Equipment, and call continuity of the call of the subscriber A from the CS domain to the IMS domain can be achieved by call switching from the UE (A) to the UE (A′).
Alike, in initial establishment of a call, an anchoring point AS can be inserted in a call path of the called party UE (B) to implement call control on subsequent domain switching of the called party
In the currently proposed call control solution of an IMS control static anchoring point, the AS with the DTF function has performed anchoring control on the present call/session, in other words, when the B2BUA function is enabled, both a status of the call terminated at the DTF and a status of the session newly initiated at the DTF are maintained at the DTF to control domain switching which may possibly be initiated by the subscriber subsequently. However, when the GMSC retrieves T-CSI from an HLR and sends again an Initial Detection Point (IDP) message to the gsmSCF with the DSF function to request a routing indication from the DSP, the IDP message carries a real called number MSISDN because the information of the called party has been recovered at the GMSC into the real called number MSISDN. Thus, in subsequent steps, the DSF can not determine whether routing control has been performed on the call in accordance with the called number MSISDN in the received IDP message, in other words, the DSF can not determine whether the present call has been routed to the IMS domain for anchoring control, resulting in repeated routing control which occurs in a subsequent call flow, so that the call can not be switched normally in the CS domain.